home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1424 < prev    next >
Text File  |  1995-07-25  |  18KB  |  508 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         B. Kaliski
  8. Request for Comments: 1424                              RSA Laboratories
  9.                                                            February 1993
  10.  
  11.  
  12.            Privacy Enhancement for Internet Electronic Mail:
  13.             Part IV: Key Certification and Related Services
  14.  
  15. Status of this Memo
  16.  
  17.    This RFC specifies an IAB standards track protocol for the Internet
  18.    community, and requests discussion and suggestions for improvements.
  19.    Please refer to the current edition of the "IAB Official Protocol
  20.    Standards" for the standardization state and status of this protocol.
  21.    Distribution of this memo is unlimited.
  22.  
  23. Acknowledgements
  24.  
  25.    This document is the product of many discussions at RSA Data
  26.    Security, at Trusted Information Systems, and on the <pem-
  27.    dev@tis.com> mailing list.  Contributors include Dave Balenson, Jim
  28.    Bidzos, Pat Cain, Vint Cerf, Pam Cochrane, Steve Dusse, Jeff Fassett,
  29.    Craig Finseth, Jim Galvin, Mike Indovina, Bob Jueneman, Steve Kent,
  30.    John Lowry, Paul McKenney, Jeff Thompson, and Charles Wu.  This
  31.    document is the product of the Privacy-Enhanced Electronic Mail
  32.    Working Group.
  33.  
  34. 1. Executive Summary
  35.  
  36.    This document describes three types of service in support of Internet
  37.    Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate-
  38.    revocation list (CRL) storage, and CRL retrieval. Such services are
  39.    among those required of an RFC 1422 [2] certification authority.
  40.    Other services such as certificate revocation and certificate
  41.    retrieval are left to the certification authority to define, although
  42.    they may be based on the services described in this document.
  43.  
  44.    Each service involves an electronic-mail request and an electronic-
  45.    mail reply. The request is either an RFC 1421 [1] privacy-enhanced
  46.    message or a message with a new syntax defined in this document. The
  47.    new syntax follows the general RFC 1421 syntax but has a different
  48.    process type, thereby distinguishing it from ordinary privacy-
  49.    enhanced messages. The reply is either an RFC 1421 privacy-enhanced
  50.    message, or an ordinary unstructured message.
  51.  
  52.    Replies that are privacy-enhanced messages can be processed like any
  53.    other privacy-enhanced message, so that the new certificate or the
  54.    retrieved CRLs can be inserted into the requestor's database during
  55.  
  56.  
  57.  
  58. Kaliski                                                         [Page 1]
  59.  
  60. RFC 1424        Key Certification and Related Services     February 1993
  61.  
  62.  
  63.    normal privacy-enhanced mail processing.
  64.  
  65.    Certification authorities may also require non-electronic forms of
  66.    request and may return non-electronic replies. It is expected that
  67.    descriptions of such forms, which are outside the scope of this
  68.    document, will be available through a certification authority's
  69.    "information" service.
  70.  
  71. 2. Overview of Services
  72.  
  73.    This section describes the three services in general terms.
  74.  
  75.    The electronic-mail address to which requests are sent is left to the
  76.    certification authority to specify. It is expected that certification
  77.    authorities will advertise their addresses as part of an
  78.    "information" service. Replies are sent to the address in the
  79.    "Reply-To:" field of the request, and if that field is omitted, to
  80.    the address in the "From:" field.
  81.  
  82. 2.1 Key Certification
  83.  
  84.    The key-certification service signs a certificate containing a
  85.    specified subject name and public key. The service takes a
  86.    certification request (see Section 3.1), signs a certificate
  87.    constructed from the request, and returns a certification reply (see
  88.    Section 3.2) containing the new certificate.
  89.  
  90.    The certification request specifies the requestor's subject name and
  91.    public key in the form of a self-signed certificate. The
  92.    certification request contains two signatures, both computed with the
  93.    requestor's private key:
  94.  
  95.      1.   The signature on the self-signed certificate, having the
  96.           cryptographic purpose of preventing a requestor from
  97.           requesting a certificate with another party's public key.
  98.           (See Section 4.)
  99.  
  100.      2.   A signature on some encapsulated text, having the
  101.           practical purpose of allowing the certification authority
  102.           to construct an ordinary RFC 1421 privacy-enhanced
  103.           message as a reply, with user-friendly encapsulated text.
  104.           (RFC 1421 does not provide for messages with
  105.           certificates but no encapsulated text; and the self-
  106.           signed certificate is not "user friendly" text.) The text
  107.           should be something innocuous like "Hello world!"
  108.  
  109.    A requestor would typically send a certification request after
  110.    generating a public-key/private-key pair, but may also do so after a
  111.  
  112.  
  113.  
  114. Kaliski                                                         [Page 2]
  115.  
  116. RFC 1424        Key Certification and Related Services     February 1993
  117.  
  118.  
  119.    change in the requestor's distinguished name.
  120.  
  121.    A certification authority signs a certificate only if both signatures
  122.    in the certification request are valid.
  123.  
  124.    The new certificate contains the subject name and public key from the
  125.    self-signed certificate, and an issuer name, serial number, validity
  126.    period, and signature algorithm of the certification authority's
  127.    choice. (The validity period may be derived from the self-signed
  128.    certificate.) Following RFC 1422, the issuer may be any whose
  129.    distinguished name is superior to the subject's distinguished name,
  130.    typically the one closest to the subject. The certification authority
  131.    signs the certificate with the issuer's private key, then transforms
  132.    the request into a reply containing the new certificate (see Section
  133.    3.2 for details).
  134.  
  135.    The certification reply includes a certification path from the new
  136.    certificate to the RFC 1422 Internet certification authority. It may
  137.    also include other certificates such as cross-certificates that the
  138.    certification authority considers helpful to the requestor.
  139.  
  140. 2.2 CRL Storage
  141.  
  142.    The CRL storage service stores CRLs. The service takes a CRL-storage
  143.    request (see Section 3.3) specifying the CRLs to be stored, stores
  144.    the CRLs, and returns a CRL-storage reply (see Section 3.4)
  145.    acknowledging the request.
  146.  
  147.    The certification authority stores a CRL only if its signature and
  148.    certification path are valid, following concepts in RFC 1422
  149.    (Although a certification path is not required in a CRL-storage
  150.    request, it may help the certification authority validate the CRL.)
  151.  
  152. 2.3 CRL Retrieval
  153.  
  154.    The CRL retrieval service retrieves the latest CRLs of specified
  155.    certificate issuers. The service takes a CRL-retrieval request (see
  156.    Section 3.5), retrieves the latest CRLs the request specifies, and
  157.    returns a CRL-retrieval reply (see Section 3.6) containing the CRLs.
  158.  
  159.    There may be more than one "latest" CRL for a given issuer, if that
  160.    issuer has more than one public key (see RFC 1422 for details).
  161.  
  162.    The CRL-retrieval reply includes a certification path from each
  163.    retrieved CRL to the RFC 1422 Internet certification authority. It
  164.    may also include other certificates such as cross-certificates that
  165.    the certification authority considers helpful to the requestor.
  166.  
  167.  
  168.  
  169.  
  170. Kaliski                                                         [Page 3]
  171.  
  172. RFC 1424        Key Certification and Related Services     February 1993
  173.  
  174.  
  175. 3. Syntax
  176.  
  177.    This section describes the syntax of requests and replies for the
  178.    three services, giving simple examples.
  179.  
  180. 3.1 Certification request
  181.  
  182.    A certification request is an RFC 1421 MIC-ONLY or MIC-CLEAR
  183.    privacy-enhanced message containing a self-signed certificate. There
  184.    is only one signer.
  185.  
  186.    The fields of the self-signed certificate (which has type
  187.    Certificate, as in RFC 1422) are as follows:
  188.  
  189.      version is 0
  190.  
  191.      serialNumber is arbitrary; the value 0 is suggested unless the
  192.           certification authority specifies otherwise
  193.  
  194.      signature is the algorithm by which the self-signed
  195.           certificate is signed; it need not be the same as the
  196.           algorithm by which the requested certificate is to be
  197.           signed
  198.  
  199.      issuer is the requestor's distinguished name
  200.  
  201.      validity is arbitrary; the value with start and end both at
  202.           12:00am GMT, January 1, 1970, is suggested unless the
  203.           certification authority specifies otherwise
  204.  
  205.      subject is the requestor's distinguished name
  206.  
  207.      subjectPublicKeyInfo is the requestor's public key
  208.  
  209.    The requestor's MIC encryption algorithm must be asymmetric (e.g.,
  210.    RSA) and the MIC algorithm must be keyless (e.g., RSA-MD2, not MAC),
  211.    so that anyone can verify the signature.
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Kaliski                                                         [Page 4]
  227.  
  228. RFC 1424        Key Certification and Related Services     February 1993
  229.  
  230.  
  231.    Example:
  232.  
  233.    To: cert-service@ca.domain
  234.    From: requestor@host.domain
  235.  
  236.    -----BEGIN PRIVACY-ENHANCED MESSAGE-----
  237.    Proc-Type: 4,MIC-ONLY
  238.    Content-Domain: RFC822
  239.    Originator-Certificate: <requestor's self-signed certificate>
  240.    MIC-Info: RSA,RSA-MD2,<requestor's signature on text>
  241.  
  242.    <text>
  243.    -----END PRIVACY-ENHANCED MESSAGE-----
  244.  
  245. 3.2 Certification reply
  246.  
  247.    A certification reply is an RFC 1421 MIC-ONLY or MIC-CLEAR privacy-
  248.    enhanced message containing a new certificate, its certification path
  249.    to the RFC 1422 Internet certification authority, and possibly other
  250.    certificates. There is only one signer. The "MIC-Info:" field and
  251.    encapsulated text are taken directly from the certification request.
  252.    The reply has the same process type (MIC-ONLY or MIC-CLEAR) as the
  253.    request.
  254.  
  255.    Since the reply is an ordinary privacy-enhanced message, the new
  256.    certificate can be inserted into the requestor's database during
  257.    normal privacy-enhanced mail processing. The requestor can forward
  258.    the reply to other requestors to disseminate the certificate.
  259.  
  260.    Example:
  261.  
  262.    To: requestor@host.domain
  263.    From: cert-service@ca.domain
  264.  
  265.    -----BEGIN PRIVACY-ENHANCED MESSAGE-----
  266.    Proc-Type: 4,MIC-ONLY
  267.    Content-Domain: RFC822
  268.    Originator-Certificate: <requestor's new certificate>
  269.    Issuer-Certificate: <issuer's certificate>
  270.    MIC-Info: RSA,RSA-MD2,<requestor's signature on text>
  271.  
  272.    <text>
  273.    -----END PRIVACY-ENHANCED MESSAGE-----
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Kaliski                                                         [Page 5]
  283.  
  284. RFC 1424        Key Certification and Related Services     February 1993
  285.  
  286.  
  287. 3.3 CRL-storage request
  288.  
  289.    A CRL-storage request is an RFC 1421 CRL-type privacy-enhanced
  290.    message containing the CRLs to be stored and optionally their
  291.    certification paths to the RFC 1422 Internet certification authority.
  292.  
  293.    Example:
  294.  
  295.    To: cert-service@ca.domain
  296.    From: requestor@host.domain
  297.  
  298.    -----BEGIN PRIVACY-ENHANCED MESSAGE-----
  299.    Proc-Type: 4,CRL
  300.    CRL: <CRL to be stored>
  301.    Originator-Certificate: <CRL issuer's certificate>
  302.    CRL: <another CRL to be stored>
  303.    Originator-Certificate: <other CRL issuer's certificate>
  304.    -----END PRIVACY-ENHANCED MESSAGE-----
  305.  
  306. 3.4 CRL-storage reply
  307.  
  308.    A CRL-storage reply is an ordinary message acknowledging the storage
  309.    of CRLs. No particular syntax is specified.
  310.  
  311. 3.5 CRL-retrieval request
  312.  
  313.    A CRL-retrieval request is a new type of privacy-enhanced message,
  314.    distinguished from RFC 1421 privacy-enhanced messages by the process
  315.    type CRL-RETRIEVAL-REQUEST.
  316.  
  317.    The request has two or more encapsulated header fields: the required
  318.    "Proc-Type:" field and one or more "Issuer:" fields. The fields must
  319.    appear in the order just described. There is no encapsulated text, so
  320.    there is no blank line separating the fields from encapsulated text.
  321.  
  322.    Each "Issuer:" field specifies an issuer whose latest CRL is to be
  323.    retrieved. The field contains a value of type Name specifying the
  324.    issuer's distinguished name. The value is encoded as in an RFC 1421
  325.    "Originator-ID-Asymmetric:" field (i.e., according to the Basic
  326.    Encoding Rules, then in ASCII).
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Kaliski                                                         [Page 6]
  339.  
  340. RFC 1424        Key Certification and Related Services     February 1993
  341.  
  342.  
  343.    Example:
  344.  
  345.    To: cert-service@ca.domain
  346.    From: requestor@host.domain
  347.  
  348.    -----BEGIN PRIVACY-ENHANCED MESSAGE-----
  349.    Proc-Type: 4,CRL-RETRIEVAL-REQUEST
  350.    Issuer: <issuer whose latest CRL is to be retrieved>
  351.    Issuer: <another issuer whose latest CRL is to be retrieved>
  352.    -----END PRIVACY-ENHANCED MESSAGE-----
  353.  
  354. 3.6 CRL-retrieval reply
  355.  
  356.    A CRL-retrieval reply is an RFC 1421 CRL-type privacy-enhanced
  357.    message containing retrieved CRLs, their certification paths to the
  358.    RFC 1422 Internet certification authority, and possibly other
  359.    certificates.
  360.  
  361.    Since the reply is an ordinary privacy-enhanced message, the
  362.    retrieved CRLs can be inserted into the requestor's database during
  363.    normal privacy-enhanced mail processing. The requestor can forward
  364.    the reply to other requestors to disseminate the CRLs.
  365.  
  366.    Example:
  367.  
  368.    To: requestor@host.domain
  369.    From: cert-service@ca.domain
  370.  
  371.    -----BEGIN PRIVACY-ENHANCED MESSAGE-----
  372.    Proc-Type: 4,CRL
  373.    CRL: <issuer's latest CRL>
  374.    Originator-Certificate: <issuer's certificate>
  375.    CRL: <other issuer's latest CRL>
  376.    Originator-Certificate: <other issuer's certificate>
  377.    -----END PRIVACY-ENHANCED MESSAGE-----
  378.  
  379.  
  380. Patent Statement
  381.  
  382.    This version of Privacy Enhanced Mail (PEM) relies on the use of
  383.    patented public key encryption technology for authentication and
  384.    encryption.  The Internet Standards Process as defined in RFC 1310
  385.    requires a written statement from the Patent holder that a license
  386.    will be made available to applicants under reasonable terms and
  387.    conditions prior to approving a specification as a Proposed, Draft or
  388.    Internet Standard.
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Kaliski                                                         [Page 7]
  395.  
  396. RFC 1424        Key Certification and Related Services     February 1993
  397.  
  398.  
  399.    The Massachusetts Institute of Technology and the Board of Trustees
  400.    of the Leland Stanford Junior University have granted Public Key
  401.    Partners (PKP) exclusive sub-licensing rights to the following
  402.    patents issued in the United States, and all of their corresponding
  403.    foreign patents:
  404.  
  405.       Cryptographic Apparatus and Method
  406.       ("Diffie-Hellman")............................... No. 4,200,770
  407.  
  408.       Public Key Cryptographic Apparatus
  409.       and Method ("Hellman-Merkle").................... No. 4,218,582
  410.  
  411.       Cryptographic Communications System and
  412.       Method ("RSA")................................... No. 4,405,829
  413.  
  414.       Exponential Cryptographic Apparatus
  415.       and Method ("Hellman-Pohlig").................... No. 4,424,414
  416.  
  417.    These patents are stated by PKP to cover all known methods of
  418.    practicing the art of Public Key encryption, including the variations
  419.    collectively known as El Gamal.
  420.  
  421.    Public Key Partners has provided written assurance to the Internet
  422.    Society that parties will be able to obtain, under reasonable,
  423.    nondiscriminatory terms, the right to use the technology covered by
  424.    these patents.  This assurance is documented in RFC 1170 titled
  425.    "Public Key Standards and Licenses".  A copy of the written assurance
  426.    dated April 20, 1990, may be obtained from the Internet Assigned
  427.    Number Authority (IANA).
  428.  
  429.    The Internet Society, Internet Architecture Board, Internet
  430.    Engineering Steering Group and the Corporation for National Research
  431.    Initiatives take no position on the validity or scope of the patents
  432.    and patent applications, nor on the appropriateness of the terms of
  433.    the assurance.  The Internet Society and other groups mentioned above
  434.    have not made any determination as to any other intellectual property
  435.    rights which may apply to the practice of this standard. Any further
  436.    consideration of these matters is the user's own responsibility.
  437.  
  438. Security Considerations
  439.  
  440.    The self-signed certificate (Section 3.1) prevents a requestor from
  441.    requesting a certificate with another party's public key. Such an
  442.    attack would give the requestor the minor ability to pretend to be
  443.    the originator of any message signed by the other party. This attack
  444.    is significant only if the requestor does not know the message being
  445.    signed, and the signed part of the message does not identify the
  446.    signer. The requestor would still not be able to decrypt messages
  447.  
  448.  
  449.  
  450. Kaliski                                                         [Page 8]
  451.  
  452. RFC 1424        Key Certification and Related Services     February 1993
  453.  
  454.  
  455.    intended for the other party, of course.
  456.  
  457. References
  458.  
  459.    [1] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
  460.        I: Message Encryption and Authentication Procedures", RFC 1421,
  461.        DEC, February 1993.
  462.  
  463.    [2] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part
  464.        II: Certificate-Based Key Management", RFC 1422, BBN, February
  465.        1993.
  466.  
  467.    [3] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
  468.        Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS,
  469.        February 1993.
  470.  
  471. Author's Address
  472.  
  473.        Burton S. Kaliski, Jr.
  474.        RSA Laboratories (a division of RSA Data Security, Inc.)
  475.        10 Twin Dolphin Drive
  476.        Redwood City, CA  94065
  477.  
  478.        Phone: (415) 595-7703
  479.        FAX: (415) 595-4126
  480.        EMail: burt@rsa.com
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Kaliski                                                         [Page 9]
  507.  
  508.